終於來到了第30天！ 我有種進入地獄豆腐料理的經歷七八五十六難終於到了最後一關的感覺？今天我們來回顧這段旅程，看看這些刻意練習，怎麼讓我們一步步走向專業之路！
這 30 天的鐵人賽中，我們進行了各種測試挑戰，從尋找問題、測試設計、測試計畫、API 效能測試、多任務負載測試、系統性能瓶頸分析，到混沌工程實驗，無一不是充滿技術含量與趣味的挑戰。今天，我將綜合這些挑戰，為這場技術馬拉松畫上圓滿的句號。
整個鐵人賽的過程，涵蓋了不同的測試策略、方法及工具的實踐與應用。這段旅程展示了如何系統化地應對不同測試場景中的挑戰，並且提出了有效的解決方案。具體的挑戰包含以下幾個重要領域：
探索 bug：建模方式與測試案例
就如同前一天的文章，好奇心與隨著探索並學習是所有事物的起點，這部分的挑戰讓我們理解了如何使用不同的測試建模方式來建立測試覆蓋率。透過一頁式的測試計畫，清楚地羅列了測試範圍與關鍵點，以適應敏捷風格下的時程，同時測試金字塔模型提供一個基準，幫助我們思考測試策略，單元測試、整合測試與端對端測試在產品上的測試。
不同測試設計方法
等價類別覆蓋法、ACC 模型、狀態機、因果圖、決策表測試，這些設計因應不同的產品特點，而會導致不同的測試涵蓋和風險管理，在設計如演唱會門票系統這類多輸入條件的情境時，決策表測試法幫助我們系統化地列出所有可能的條件組合，並且覆蓋所有重要的測試情境。這個方法在面對複雜邏輯設計時，而隨著功能的需求改變，有時必須要使用不同的設計方法，才有機會找到新的問題。
Playwright 在 API/UI 自動化測試的應用
自動化測試幫助我們撰寫已知的測試案例，某種程度釋放手動反覆測試相同情境的地獄循環，透過 Playwright 寫 UI 和 API 測試，並驗證伺服器回應資料，讓我們深入了解如何確保 API 的穩定性與可靠性。這部分挑戰了我們在多變且快速環境中的應對能力，尤其是在面對大型系統中的 API 測試或是反覆驗證的測試 (Regression Testing) 顯得特別重要。
效能分析與多任務負載測試
在這篇文章中，我們透過多任務負載測試來模擬多用戶進行不同操作的情況。透過 K6 模擬了數萬用戶同時觀看和上傳影片的場景，從這個資料庫練習，我們了解效能測試的基本流程和步驟。並且使用 K6 模擬的併發負載測試，讓我們能夠準確定位系統瓶頸。
效能測試融入 CI/CD 流程
一個強大的 CI/CD 流程，必須能及時發現效能問題。在這篇文章中，我們討論了如何將效能測試融入日常的 CI/CD 流程中，並證明這樣的整合方式可以提前發現潛在的效能瓶頸，大大減少了後期修復的成本。
混沌工程：挑戰系統的極限
在這部分，我們使用 Chaos Toolkit 模擬故障場景，從網路延遲到 CPU 過載，再到記憶體耗盡，驗證了系統的穩定性與容錯能力。雖然我覺得透過混沌測試來發掘系統的真實極限，有時候研究成本太高，不如在生產環境觀察異常指標，在專心研究問題原因，但這個練習了解混沌測試的流程和工具。由於鐵人賽時程的關係，這道練習不算是一個好的範例，之後有遇到經典的題目會在更新上來。
資料碎片化的挑戰與效能瓶頸分析
透過 K6 探索 PostgreSQL 的效能瓶頸，我們學習到「重現問題」，透過資料碎片化會如何影響查詢性能。了解什麼是資料表，並且怎麼查詢碎片化的資訊，和碎片化的程度會加劇效能瓶頸。在這篇中，雖然我們沒有發現當資料表產生碎片後，查詢效能明顯下降，但我們能夠繼續探索下去，並且透過假設和反覆實驗，會發現效能下降，並且驗證效能的改善 。
在這 30 天的挑戰中，我希望透過實際操作再理解理論的過程來強調「實踐後再理論」的重要。從測試計畫的撰寫，到效能測試測試工具等實踐應用，甚至在混沌工程的設計中，我們一步步理解測試理論和工具。這讓每次練習都能更深刻地理解了每一個工具和策略的核心價值，也能幫助在日後的工作中更加游刃有餘地處理類似挑戰。
題目設計盡量貼近生活化，而非單純針對實際工作中遇到的系統。除了增添趣味，另一個層面是希望透過生活化的方式，更加貼近『人』的思考。就像在測試這份工作中，除了產品經理外，測試人員往往是團隊裡最需要了解產品流程，並從『使用者角度』出發思考的代言人。畢竟測試人員有時候就是那個幫忙產品經理補充、了解使用者需求和體驗的橋梁，從不同的生活場景來思考，或許能發現更多潛在的問題或需求。
30 天的鐵人賽雖然結束，但探索永無止境。這段旅程讓我不僅重新複習對測試理論的理解，也透過實踐學習到了很多難以從書本中獲得的經驗，並且透過挑戰能夠更加理解測試的東西。
這是我在鐵人賽中的最後一天，但絕不是我的終點。希望這 30 天的文章能夠幫助到更多的讀者，也期待我們在未來的技術世界中再次相遇！
iThome鐵人賽
看影片追技術